Virtual machines are known in the art. Generally, a virtual machine is a software component that emulates a physical computer, enabling software applications to run or execute on a physical machine or computer without having to be aware of the underlying hardware.
A hypervisor (or virtual machine monitor (VMM)) is a software, firmware or hardware component that creates and runs virtual machines. A computer on which a hypervisor is running one or more virtual machines is referred to in the art as a host machine. Each virtual machine running on a hypervisor is referred to in the art as a guest machine.
To enable proper operation, a virtual machine includes, operates according to, or is associated with, a set of specifications and/or configurations (the virtualization infrastructure) that are used in order to hide the physical aspects of the underlying hardware from the applications and/or enable the virtual machine to properly interact with the underlying hypervisor.
Each different virtualization infrastructure or type has a different way of describing the properties of a virtual machine and or underlying hardware or hypervisor. Accordingly, when replicating, migrating or converting virtual machines from one type of virtualization to another, a convertor is needed in order to translate the configuration from, e.g., virtualization of type “A” to virtualization of type “B”.
Properties, configuration or attributes of a virtual machine may include a description of the emulated hardware used by the virtual machine (e.g., “virtual hardware properties” as referred to in the art). For example, properties, configuration or attributes of a virtual machine may include features or functions provided by a hypervisor and made available to a virtual machine (e.g., “high availability” as known in the art).
One of the problems associated with supporting a number of virtualization types is that the number of required convertors increases exponentially with the number of virtualization types to be supported. For example, when supporting 3 types of virtualization systems, e.g., types “A”, “B” and “C”—the following convertors are needed: A→B, A→C, B→A, B→C, C→B, C→A. Adding another (fourth) virtualization type in the above example, will result in doubling the number of convertors.
Moreover, when adding a new virtual machine type, all existing convertors must be updated in order to enable converting existing virtual machine types to the new virtual machine type. In addition, work on each convertor is typically fairly delicate and requires the developer to be familiar with all hypervisor configuration types and maintain all conversion paths to from each type of virtual machine and hypervisor. Additionally, modification of any of the hypervisors' native configuration requires an update of all convertors. Moreover, incompatibility between configurations of different hypervisors may cause loss of information when converting or translating configuration information between hypervisors.